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Page 14, Paragraph beginning on Line 17 (Amended) 



Samples of the contents of 



databases 240 and 250 are shown in FIGS. 3, 4A and 4B. The specific data and fields illustrated 
in these figures represent only sample records stored in each database. In most cases, the fields 
shown in FIGS. 3, 4A and 4B are straightforward and self-explanatory. It is to be understood 
that the data and the fields, as well as the number of databases, can be readily modified from the 
described embodiment and adapted to provide variations for receiving and processing requests 
for preferred categories of seating. Furthermore, each field may contain more or less 
information. For example, the address field may be divided into separate fields containing street 
address, apartment number, city, state, and zip code. Also, in other embodiments, the databases 
may be combined or divided into additional databases. 



Page 15, Paragraph beginning on Line 17 (Amended)} FIGS. 4 A and 4B illustrate an 



exemplary reservation database 250 that stores information for each reservation, including 
passenger requests for a preferred category of seating. Referring to FIG. 4A, the reservation 
f database maintains a plurality of records, such as records 475 - 499, each associated with a 

different reservation. For each reservation identified by the reservation number in field 405, the 
reservation database 250 stores personal information, such as the passenger's name, address and 
credit card number, in fields 410, 415, and 420, respectively. In addition, the reservation 
database 250 includes the passenger type in field 425; that is, whether the passenger is an adult, 
student, child or infant. Further, the reservation database 250 stores the class of seating the 
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passenger is confirmed for in field 430, such as coach, business or first class. The reservation 
database 250 also includes the passenger's request for a selected category of seating, and allows 
a certain number of elements for each request to be stored. A passenger's request can consist of 
multiple elements. For example, a passenger can request an aisle seat in an emergency exit row 
adjacent to a certain passenger. This request has three elements: element A, an aisle seat, 
element B, a seat in an emergency exit row and element C, a seat adjacent to a certain passenger. 
Referring to FIG. 4B, the elements of the request are recorded in fields 435, 440, 445 and 450, 
where the maximum number of fields may be predefined by the airline. The illustrative 
reservation database 250 shows fields for storing four elements of a request. In one embodiment, 
an airline may choose to limit the number of elements a passenger can specify within a request. 
In a further embodiment, the airline may choose to honor only the first two elements or any two 
specified elements of the request. Once the overall seating evaluation is executed by the central 
controller 100, the reservation database 250 stores guaranteed elements of the request in field 
465. Finally, the "flexible" seat assignment is stored in field 460 of the reservation database 250. 
If, however, the passenger has requested a direct seat assignment, then that seat number is stored 
in field 465. As the overall seating evaluation is executed and the passengers are reassigned, the 
"flexible" seat assignments are continuously updated. At any instant, the reservation database 
250 can be accessed to determine what the current seat assignment is for a given passenger. 
Once the transition point, which is the instant when the "flexible" seat assignments become 
"permanent", is defined, the seat number in field 460 will be transferred to and stored in field 
465, the field for a "permanent" seat assignment. At this point, the passenger can no longer be 
reassigned to a different seat. 
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